08 - 两个大厂实现拆解
前置：02 到 04 篇的写入 / 时间 / 读取三条链路，05 篇的文件式形态。
本篇回答：把前七篇的框架套到两个真实实现上，看它们各自在哪一步做了不一样的选择、代价落在哪里、以及有哪些问题两家都没解决。
为什么是这两个：不是因为 star 高。是因为它们在同一个问题上给出了方向相反的答案，放在一起看比单看任何一个都清楚。
本篇会用到的词：
| 词 | 意思 |
|---|---|
| 目录递归检索 | 先用向量定位到最相关的目录，再逐层下钻，而不是把全部条目拍平成一个列表去排序 |
| 记忆资产 | 腾讯的抽象：对话记忆、技能、文档 Wiki、代码图都被注册成同一类可管理对象 |
| 装备（loadout） | 把某个记忆资产绑定给某个 Agent。类比是给角色配装备，而不是给全体发广播 |
| 三级 ACL | private / team / restricted 三档可见性，第三档再按用户、角色、Agent 精确授权 |
| 影响面分析 | 改一个代码符号之前，先查出哪些地方会被这次改动波及 |
一、两者在这个专题的坐标系里站在哪
二、同一个词「层」，两种完全不同的含义
两家都说自己做了分层，也都用 L0 / L1 / L2 这套编号 —— 但指的是两回事。这是读这两份文档时最容易串的地方。
为什么腾讯那套的方向值得注意：02 篇第一节讲过抽取式和原样存两条路线的取舍 —— 抽取省地方但会丢信息，原样存不丢但检索时命中的不是答案本身。腾讯的做法是两条都留：L0 保原文用于核对措辞、时间戳和出处，L1 保抽出来的事实用于精确召回。这是把那道取舍题换成了存储成本题。
三、案例 A：OpenViking —— 把上下文当数据库
3.1 数据模型
一切挂在 viking:// 下，只有三类：
viking://
├── resources/ # 资源：项目文档、代码仓、网页
│ └── my_project/
└── user/{user_id}/
├── memories/preferences/ # 记忆：抽取出来的用户偏好
├── resources/ # 该用户私有的资源
├── skills/ # 技能
└── peers/ # 其他参与者
这个模型的取舍很清楚：牺牲表达力换确定性。它没有 03 篇那套时间字段，也没有图边 —— 换来的是 Agent 可以用 ls / tree / find 确定性地定位内容，而不是把查询丢进一个黑盒里等结果。
多租户隔离靠 user/{user_id}/ 这棵子树，结构上比 02 篇第七节说的"可选 filter 漏传就越界"更难出事。
3.2 检索：递归下钻，不是一次拍平
3.3 它没解决什么
| 前面篇目里的问题 | OpenViking 的状态 |
|---|---|
| 事实变了怎么办（03 篇） | 没有双时间轴，也没有作废语义。改了就是覆盖，问不了"三月份时是什么情况" |
| 强制注入安全类记忆（04 篇第四节） | 做不到。模型不去下钻就读不到，和 memory 工具一样是提示词层面的约束 |
| 许可证 | AGPL-3.0（crates/ov_cli 与 examples 单独 Apache-2.0）。记忆层几乎总以服务形态部署，网络分发条款会被触发 |
| 自报评测 | README 给的是"接上前后"的对比（某客户端在 LoCoMo 上 24.20% → 82.08%），基线是各客户端原生表现、嵌入模型是自家的 —— 按 07 篇第四节那套读法，这类数字说明不了它和别的记忆库谁强 |
四、案例 B：腾讯 —— 把记忆当团队资产
4.1 四类资产，同一套治理
它把四样东西注册成同一类对象：
| 资产 | 装的是什么 | 对应 01 篇的分型 |
|---|---|---|
| Chat Memory | 偏好、事实、决策、交互历史 | 语义记忆 ＋ 情景记忆 |
| Skill | 可复用的做法。带版本、资源文件、触发边界、执行步骤、校验规则 | 程序记忆 |
| Wiki | 文档变成带链接图的结构化页面 | 不属于记忆，是 RAG 语料 |
| CodeGraph | 代码符号、文件、调用关系、影响面 | 同上 |
Skill 那一行值得停一下。01 篇3.2 说过程序记忆最危险 —— 它改的是行为，且没有任何一轮对话会去纠正它，所以必须配版本管理和回归评测。腾讯这套把版本、触发边界、校验规则做进了 Skill 的结构里，是目前公开实现里唯一正面处理这个问题的。默认私有、审核后才能共享给团队，也是同一个考虑。
后两行严格说不是记忆，是 01 篇第二节划给 RAG 的东西。把它们和记忆放进同一套治理里是产品决策，不是概念混淆 —— 因为"谁能看""哪个版本有效""装给哪个 Agent"这三个问题对四者是共通的。
4.2 强制注入：这批里唯一有现成机制的
04 篇第四节留了一个问题：过敏源、禁忌药物这类记忆不能丢进向量检索里跟别的条目竞争排名，但没有任何一个开源实现提供现成机制。腾讯这套是例外。
("memories",) 也好、filters 漏传也好，都是「默认全局、靠调用方收紧」这一种设计的产物。4.3 它没解决什么
| 前面篇目里的问题 | 腾讯这套的状态 |
|---|---|
| 事实变了怎么办（03 篇） | 同样没有双时间轴。靠 L0→L3 的分层重算来覆盖旧结论，答不了"当时系统以为是什么" |
| 部署成本 | 四个服务（MemoryCore / MemoryKnowledge / MemoryPanel / MemoryProxy）＋ 数据库。是06 篇部署重量里最重的一档 |
| 异步延迟 | Wiki 与 CodeGraph 是异步构建的，要等状态变成 ready；对话也要等异步管线提炼完才有 L1 以上 |
| 私有仓支持 | CodeGraph 目前优先支持公开 HTTPS 仓库，私有仓和 SSH 凭证还在完善 |
| 自动路由 | 资产绑定目前是人工的，全自动记忆路由还在迭代 |
| 自报评测 | PersonaMem 从 48% 到 76%，同样是"接上前后"的对比，不是与其他记忆库的横向比 |
五、两者对照
| 维度 | 字节 OpenViking | 腾讯 Agent Memory |
|---|---|---|
| 统一抽象 | 虚拟文件系统 viking:// | 记忆资产 Memory Asset |
| 「层」的含义 | 同一份内容的三种详略 | 四种不同的东西，逐层提炼 |
| 检索方式 | 目录递归下钻，轨迹可回放 | 分层召回，L2/L3 铺底后回落 L1/L0 |
| 混合检索 | 向量为主 | BM25 ＋ 向量 ＋ RRF |
| 强制注入 | ❌ | ✅ 固定绑定 |
| 多租户 | user/{user_id}/ 子树 | 团队 / 用户 / Agent 三级 ACL ＋ 四档可见性 |
| 程序记忆 | skills 目录，无版本治理 | Skill 带版本、触发边界、校验规则、审核流 |
| 人的角色 | 看轨迹排查 | 审核、共享、装备 |
| 部署 | 独立 HTTP 服务，自带 compose 与 helm | 四个服务 ＋ 数据库 |
| 许可证 | AGPL-3.0 | MIT |
| 语言 | Rust ＋ Python | TypeScript |
一句话选型：卡在"资料多了 Agent 读不对"上，看 OpenViking；卡在"经验留在个人那儿传不下去、且要控制谁看得到什么"上，看腾讯那套。前者是上下文问题，后者是组织问题。
六、两家都没解决的三件事
七、能抄走的四条设计
不打算用这两个产品，这四条也值得抄进自建方案：
- 元数据和内容一起生成，不要手写。OpenViking 让每个目录都有
.abstract和.overview，随内容一起更新。手写在提示词里的那种文件说明，迟早和内容对不上 - 权限的默认值要收紧，不要放开。腾讯的资产默认私有、共享是显式动作。07 篇第三节那三处跨租户失守，根因都是"默认全局、靠调用方收紧"
- 给检索留一条不参与排序的旁路。安全类记忆走固定绑定式的无 条件注入，其余才去竞争排名
- 原文和抽取结果都留。腾讯的 L0 保原文、L1 保事实，把02 篇那道"抽取还是原样存"的取舍题换成了存储成本题 —— 存储比模型调用便宜得多
八、小结
- 两者都叫记忆，解决的问题不同：OpenViking 面向单个 Agent 的上下文，腾讯面向团队的记忆资产
- 「层」这个词在两家的含义完全不同：一个是同一份内容的详略，一个是四份不同的东西。备份与迁移策略因此不同
- 腾讯那套是目前唯一自带强制注入机制（固定绑定）和程序记忆版本治理（Skill）的公开实现
- OpenViking 的检索轨迹可回放，比事后往 trace 里补属性更彻底
- 两家都没做时间维度：没有双时间轴、没有作废语义，历史查不回来
- 两家的自报评测都是"接上前后"的对比，不能用来横向比较
← 回到 专题索引 | Agent Infra 板块总览